利用不同的AI進行開發，最大的問題就是每個AI都有自己偏愛的地方存放文件或是程式碼。雖然可以利用規則文件先行定義，然而，在開發時其實自己也不確定到底放在什麼地方是比較合適的，索性就讓AI自由發揮。不過到了一個階段，看到文件、程式碼散落，還是不得不花一些時間。

整理這部份，算是AI相當擅長的，只需要和它提及需求，它會符合到我們所想的樣子。特別是在進行git branch的整理時，我只能說它是做的又快又好。就算是程式碼有conflict，它合併處理的速度真是望塵莫及。不過實際上花在整理的時間也沒有少多少，在整理的過程又要合併，又要修正，還要執行測試，撰寫新的測試。整體時間算下來也很可觀，唯一欣慰的是它只有經手過一次，就萬事ok。

而今天除了花時間整理外，最主要的就是把Project v2建立起來了，仍是在很陽春的階段但也能看到Issue在不同的階段中進行轉化。而這裡要特別記錄的事情是GitHub的建議和實際情況的不一致。

現今的環境下，GitHub有二種Personal Access Token(PAT)，官方會建議新的專案利用”Fine-grained tokens”，可以的話避免使用”Token (classic)”，光從名稱來看，也可以了解到另一個Token是古早以前的方案。Project v1是綁在Git Repository裡的，而GitHub為了要讓Project能跨專案使用，像是有些Polyrepo，一整個案子用了相當多不同的git repo進行不同部份的開發管理，GitHub特地在升級版的Project v2中，讓整個Project抽離出來，成為Organization的層級，在這樣的架構下可以同時進行多個git repo的管理。

有趣的地方在於如果要使用Project不論是v1或是v2都是需要PAT，而此PAT裡至少要有project:read的權限。不過，”Fine-granined token”並不包含此權限的設定，如果要有此權限的token，則只能使用Token (classic)。Project v2是官方推薦的最新使用方案，卻要搭配古早的token方可進行以API的方式使用。這真的是讓人很難理解，對於GitHub不是很熟的我來說，一樣是要踩過坑才知道。

花了一些時間，也還是終於將Project v2這裡搞定了。接下來要進行的部份則是將專案主要的開發從Notion中導入成可被執行的Issue，讓現有的架構去處理後續的開發。寫到這裡才發現還沒有談過這個專案它被設計的預想為何，應該會利用明天的篇幅在做比較仔細的介紹。

另外，看到這個”開源”的專案裡的Contributor全部都是agent，bot，讓我想到玩MMORPG時的外掛，也慢慢地融入到這個現實的世界裡了。